hasInitialPosition prevents the <Map> from rendering until either initialCoordinates resolves or a selected listing has valid coordinates. On first load with no listing param, initialCoordinates starts as null (and can remain null on timeout/error), which means the map never renders and contradicts the comment that MapView falls back to DEFAULT_COORDINATES.

The IP geolocation success check uses truthiness (if (response?.latitude && response?.longitude)), which will incorrectly treat valid coordinates of 0 as missing (e.g., locations on the equator/prime meridian). Use explicit number checks (e.g., typeof === "number" and Number.isFinite) instead.

The URL-sync effect skips fetching when resolvedSlugRef.current === listingSlug, but tableName (public vs private view) can change when user becomes available/unavailable. In that case the effect will keep showing the previously fetched view and never refetch the listing with the correct columns. Consider also tracking the resolved table/view (or resetting resolvedSlugRef when tableName changes) so the listing refetches on auth state changes.

The debounce utility is typed with T extends (...args: never[]) => unknown, which suggests the wrapped function takes no arguments and is easy to trip over (and makes the types harder to understand). This helper should accept arbitrary parameters (e.g. unknown[]/any[]) so the typings match usage like debouncedFetch(bounds).

The timeout implemented via timeoutPromise can still reject after geolocation.info() wins the Promise.race, which can trigger an unhandled promise rejection in the browser. Track the timeout id and clearTimeout once the race settles (or wrap the timeout promise so its rejection is always handled), and consider clearing it in the effect cleanup as well.

fetchBySlug can race with subsequent URL changes (or view flips): an earlier request resolving late will still call setSelectedListing and overwrite the newer selection. Add stale-request protection (e.g., a requestIdRef/token captured per call and checked before setting state, or AbortController if supported) so only the latest slug/tableName result is applied.

selectListingById has the same out-of-order response risk: if a user taps multiple pins quickly, a slower first request can resolve after the later one and overwrite selectedListing / URL with the wrong listing. Introduce a per-selection request token (or AbortController) and ignore results that are no longer current before calling setSelectedListing / router.push.

onOpenChange provides the next open state, but handleDrawerOpenChange ignores the argument and always calls closeListing() whenever a listing is selected. This can inadvertently close the drawer if the callback fires on open as well as close. Accept the open boolean and only call closeListing() when open === false.

getListingCoordinates currently relies on isListing(listing as SelectedListing) plus casts, which is confusing and can mis-classify non-Listing shapes (e.g. ListingMarker) because isListing only checks error !== true. Consider switching to an explicit isListingError/'error' in listing check and narrowing without casts, or split overloads for SelectedListing vs ListingMarker to keep the type guard accurate.

In the desktop scroll-listener effect, the handler is only attached inside the MutationObserver callback. If drawerContentRef.current is already set when the effect runs (likely, since refs are assigned before effects), no DOM mutation may occur and the scroll listener never attaches, so the sticky header state won’t update on desktop. Attach the listener immediately when drawerContentRef.current is non-null, and only fall back to MutationObserver when it’s still null.

On fetch failure in selectListingById, the hook sets selectedListing to an error sentinel but does not update the URL. Since the drawer open/close state is URL-driven, this error state may never be shown (when no listing is in the URL), or it can momentarily show an error while the URL still points at the previous listing (state/URL mismatch). Consider keeping selectedListing unchanged on failure (and just clear the optimistic id), or explicitly push a URL state that matches the error/closed state so UI + URL stay consistent.

padBounds expands west/east longitudes without normalizing them into a valid range or handling antimeridian wrapping. With renderWorldCopies enabled, LngLatBounds can be “unwrapped”, and padding increases the chance of west/east falling outside [-180, 180] (or producing a box that crosses the dateline), which can break the listings_in_view RPC bounding-box query. Consider wrapping/clamping longitudes (and splitting into two bboxes when crossing the antimeridian) before issuing the request.

In selectListingById, when the fetch-by-id fails you clear optimisticListingId to null while leaving selectedListing and the URL pointing at the previously selected listing. This can leave the drawer showing listing A but with no pin highlighted (because selectedListingId is derived only from optimisticListingId). Consider restoring the optimistic id back to the current resolved listing id (or tracking the previous selected id in a ref) on failure instead of setting it to null.

When the URL loses listingSlug (e.g. user hits browser Back while a fetchBySlug request is in-flight), the in-flight request token is not invalidated. A late response can still pass the token check and set selectedListing/optimisticListingId, re-selecting a pin even though the URL has no listing. Consider incrementing requestTokenRef.current (same as closeListing) when listingSlug becomes null to cancel any outstanding fetches.

createClient() creates a new Supabase browser client on every render (see src/utils/supabase/client.ts). Because supabase is a dependency of fetchBySlug/selectListingById, this causes unnecessary callback churn and can trigger extra effect work. Memoize the client with useMemo (or hoist it into a stable ref) so the same instance is reused across renders.

DEFAULT_COORDINATES includes a zoom property but current callers (e.g. MapView.resolveInitialViewState) never use it, and instead fall back to ZOOM_LEVEL_DEFAULT. This is internally inconsistent and makes it easy for the fallback zoom to drift from the documented default. Either remove zoom from DEFAULT_COORDINATES or use it as the ultimate zoom fallback to keep the source of truth unambiguous.

When skip is true, this effect returns without ever setting initialCoordinates. Downstream, MapView currently gates rendering the map on Boolean(initialCoordinates) unless the selected listing has valid coordinates. This combination can prevent the map from mounting for deep links that resolve to an error sentinel or to a listing with coordinates: null. Consider setting initialCoordinates to the default fallback immediately when skip is true (or otherwise guaranteeing a non-null value), while still avoiding the IP geolocation request.

hasInitialPosition only becomes true when the selected listing has valid coordinates or initialCoordinates is set. When the page is deep-linked (skip: true in useIpInitialLocation) and the slug is invalid (or the listing has coordinates: null), initialCoordinates never resolves and hasValidCoordinates(selectedListing) is false, so the <Map> never mounts and the page renders an empty map container. Consider allowing the map to mount with DEFAULT_COORDINATES (or ensuring initialCoordinates is always set even when skip is true), so deep links to missing/coordinate-less listings still show the map + error drawer instead of a blank screen.